1. Field of the Invention
The invention generally relates to methods for programming and more particularly relates to programming a BIOS (Basic Input/Output System) or in a system with highly restricted system resources.
2. Description of the Related Art
When a computer system starts up, typically it first runs instructions on the processor(s) which are stored in a BIOS (Basic Input/Output System). These instructions may initialize the system and may help the system determine how it is configured and how it may operate. Due to the state of the system at the time, the instructions in the BIOS are typically restricted to instructions that can be run solely on the processor. The system may have random access memory installed, but that fact needs to be discovered by the processor before the random access memory may be used, so until the presence and configuration of random access memory has been established, the processor must not execute instructions that use random access memory. As a result, code written in high-level languages such as C may not be used to directly implement the instructions in the BIOS until memory is configured for proper system operation. In particular, no code which uses a stack for passing procedure/function calls and arguments may be used, as a stack is typically allocated in system memory. The only memory available is that in the BIOS (which is usually FLASH ROM and therefore unsuitable for temporary storage) and memory contained within the processor (typically registers). Furthermore, the memory used is relatively expensive, so the more of it that is used, the more expensive the system becomes.
This startup environment is highly restricted as described, but also does not demand sophisticated programs. The contents of the BIOS are fairly simple routines for determining if memory (such as random access memory) is included in the system, where any included memory is in the physical addressing space, what other peripheral devices are attached to the system, and whether any malfunctions are occurring. Unfortunately, if there is a problem in the BIOS code itself, that is very difficult to find, as the traditional debugging techniques such as observing messages on a screen from embedded parts of code or reading a file containing a step-by-step description of what processing occurs are not available when running BIOS code under startup conditions. Traditional debugging techniques require system resources that the BIOS code must initialize, and those system resources may not be used without first undergoing initialization. If a BIOS in a system that is out in the public fails, chances are that either the system will fail to start properly, leaving it wholly nonfunctional, or it will have some sort of intermittent error due to a relatively minor bug in the BIOS which only affects a non-critical portion of the system. In either case, those attempting to isolate and fix the error will often have tremendous difficulty isolating the error.
The BIOS code is typically written in assembly language, written at a low enough level that an assembler may easily convert it to native instructions for a processor (machine language). At this level, code is typically written such that if a procedure or function call is specified, rather than having the code jump to the procedure or function, the code for the procedure or function is inserted at the point where the procedure or function call was specified. This results in duplicated procedure or function code and larger than necessary code size. It also makes debugging the code difficult, as it does not exactly correspond to what was written prior to assembly of the code. Furthermore, much of the code may be devoted to moving operands into specific registers for purposes of the procedure or function execution, then moving the operands back to where the operands came from. Moreover, these operands are often parameters that are not varied within the procedure or function, they are simply necessary as reference values for the execution of the procedure or function.
One alternative to this coding scheme is use of a table of function calls which may be executed sequentially. In that case, the function calls are not replaced by the actual function code, so debugging is somewhat easier. However, tables typically must have all entries identical in size, which means that each entry must have a place for the information necessary in all other entries. This results in a table wherein most of the entries use only a small portion of the total memory allocated to each entry, and therefore results in significantly larger than desired code. Furthermore, the developer of the table is in a position to make many simple mistakes due to the complexity of maintaining a large and unwieldy table of entries. Additionally, some sort of engine must be written to sequence through the table, and that engine will require even more code to implement.
The invention, in one embodiment, is an apparatus. The apparatus includes an effector having executable code. The apparatus also includes a macro having a reference to the effector.